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REMARKS 

The following remarks are made in response to the Office Action mailed January 13, 
2005. Claims 2-47 were rejected. Claims 2-47 remain pending in the application and are 
presented for reconsideration and allowance. 

Claim Objections 

The Examiner objected to the ordering of the claims because a series of singular 
dependent claims is permissible in which a dependent claim refers to a preceding claim 
which, in turn, refers to another preceding claim, but a claim which depends from a 
dependent claim should not be separated by any claim which does not also depend from said 
dependent claim. Applicants respectfully acknowledge that claim 11 (depends from claim 4) 
is separated from claim 6 (depends from claim 4) by claims 7-10 (do not depend from claim 
4). Applicants respectfully request that the ordering of these claims be changed prior to 
issuance. 

Claim Rejections under 35 U.S.C. § 103 

The Examiner rejected claims 2-18, 22, 25-41, and 45 under 35 U.S.C. § 103(a) as 
being unpatentable over the Request for Comment 793, Transmission Control Protocol (Sept. 
1981) (RFC 793) reference and the P.V. Mockapetris, Analysis of Reliable Multicast 
Algorithms for Local Networks, ACM (1983) reference. 

The Examiner rejected claims 19-21 and 42-44 under 35 U.S.C. § 103(a) as being 
unpatentable over the RFC 793 reference and the Mockapetris reference, and further in view 
of the J.M. Aldrich (USNET post, Oct. 16, 1997) reference. 

The Examiner rejected claims 23-24 and 46-47 under 35 U.S.C. § 103(a) as being 
unpatentable over the RFC 793 reference and the Mockapetris reference, and further in view 
of the Request for Comment 2236, Internet Group Management Protocol, Version 2 (Nov. 
1997) (RFC 2236) reference. 

The RFC 793 reference does not teach or suggest the limitations in independent claim 
2 of multiple end-to-end contexts, each end-to-end context having a portion storing state 
information at the source node and a portion storing state information at a corresponding one 
of the destination endnodes to ensure the reception and sequencing of message data multicast 
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from the source endnode to the corresponding one of the destination endnodes, wherein a 
reliable multicast comprises a series of replicated unicasts of message data through the send 
work queue and each of the end-to-end context portions at the source endnode to the receive 
work queue and the corresponding end-to-end context portion of each of the destination 
endnodes. 

The RFC 793 reference also does not teach or suggest the method of independent 
claim 25 of multicasting in a distributed computer system including a source endnode 
participating in a multicast group and multiple destination endnodes participating in the 
multicast group including storing in each of multiple end-to-end contexts state information at 
the source node and state information at a corresponding one of the destination endnodes to 
ensure the reception and sequencing of message data multicast from the source endnode to 
the corresponding one of the destination endnodes, and reliably multicasting data including 
performing a series of replicated unicasts of message data to the send work queue and each of 
portions of the end-to-end contexts at the source endnode to the receive work queue and 
corresponding end-to-end context portions of each of the destination endnodes. 

First, as admitted by the Examiner, the RFC 793 reference fails to disclose a reliable 
multicast to a group of destination endnodes wherein the reliable multicast comprises a series 
of replicated unicasts to each endnode. 

In addition, the RFC 793 reference teaches the transmission control protocol (TCP) 
which employs a reliable connection service between two processes. A similar reliable 
connection service to communicate between distributed processes is illustrated in Figure 3 
and described from page 12, line 20-page 14, line 9 of the Present Specification. The TCP 
reliable connection service and the reliable connection service described and illustrated in the 
Present Specification both require an association of a local send buffer or queue and receive 
buffer or queue (i.e., queue pair (QP)) with one and only one remote QP. In a reliable 
connection service a non-sharable resource connection must be established between a source 
process and a destination process. The connection establishment and clearing of the TCP 
reliable connection service is described in Section 2.7, beginning at page 10 of the RFC 793 
reference, which states that a connection is fully specified by the pair of sockets at the ends, 
and the connection can be used to carry data in both directions, that is, it is full duplex. 
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A reliable connection service, such as disclosed in the RFC 793 reference and 
disclosed in the Present Specification, requires a process to create a QP for each process 
which it is to communicate with over a network. 

By contrast, the distributed computer system of independent claim 2 and the method 
of multicasting in a distributed computer system of independent claim 25 employ multiple 
end-to-end contexts, each having a portion storing state information at the source node and a 
portion storing state information at a corresponding one of the destination endnodes to ensure 
the reception and sequencing of message data multicast from the source endnode to the 
corresponding one of the destination endnodes, wherein a reliable multicast comprises a 
series of replicated unicasts of message data through the send work queue and each of the 
end-to-end context portions at the source endnode to the receive work queue and the 
corresponding end-to-end context portions at each of the destination endnodes. Embodiments 
of reliable multi-unicast services are described in detail beginning at page 33, line 12 and 
correspondingly illustrated in Figure 13 of the Present Specification. 

The end-to-end contexts at the source endnode and the destination endnodes as recited 
in independent claim 1 and independent claim 11 permit mupltiple reliable unicast services, 
such as reliable datagram services, to be established between the source node and the 
destination endnodes. The established reliable unicast services, such as reliable datagram 
services are effectively connectionless as a result of the end-to-end contexts at the source 
endnode and the destination endnodes, which can greatly improve scalability. 

Moreover, the Mockapetris reference does not teach or suggest the limitations of 
independent claim 1 of a reliable multicast comprising a series of replicated unicasts of 
message data through the send work queue and each of the end-to-end context portions at the 
source endnode to the receive work queue and the corresponding end-to-end context portion 
at each of the destination endnodes. 

The Mockapetris reference also does not teach or suggest the limitations of 
independent claim 25 of reliably multicasting data including performing a series of replicated 
unicasts of message data through the send work queue and each of portions of the end-to-end 
contexts at the source endnode to the receive work queue and corresponding end-to-end 
context portions at each of the destination endnodes. 
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By contrast, the Mockapetris reference teaches simulation of a multicast in a local 
network which lacks any sort of one-to-many transmission capability. In the Mockapetris 
reference, the sender merely transmits separate messages to each destination and receives 
separate acknowledgements in return. Each destination requires two transmissions, so that a 
multicast set of N destinations require 2 N transmissions. Each transmission is created and 
received by a host, so a grand total of 4 N packets are processed by all hosts. As stated in the 
Mockapetris reference at page 153, column 2, this simulated multicast is "usually the most 
expensive." 

Thus, the Mockapetris simulated multicast is a straightforward way for a local 
network which lacks any sort of one-to-many transmission capabilities to simulate a 
multicast, but the method is "usually the most expensive" to implement. 

By contrast, the distributed computer system of independent claim 2 and the method 
of multicasting in a distributed computer system of independent claim 25 employ multiple 
end-to-end contexts, each end-to-end context having a portion storing state information at the 
source node and a portion storing state information at a corresponding one of the destination 
endnodes to ensure the reception and sequencing of message data multicast from the source 
endnode to the corresponding one of the destination endnodes to ensure the reception and 
sequencing of message data multicast from the source endnode to the corresponding one of 
the destination endnodes to provide a reliable multicast which has one-to-many transmission 
capability (i.e., not just a simulated expensive multicast) which comprises a series of 
replicated unicasts of message data through the send work queue and each of the end-to-end 
contexts portions of the source endnode to the receive work queue and the corresponding 
end-to-end context portion at each of the destination endnodes. 

Therefore, the RFC 793 reference and the Mockapetris reference do not teach or 
suggest alone or in combination all of the limitations of the distributed computer system of 
independent claim 2 or all of the limitations of the method of independent claim 25. In 
addition, dependent claims 3-24 further define patentably distinct independent claim 2, and 
dependent claims 26-47 further define patentably distinct independent claim 25. Therefore, 
dependent claims 3-24 and 26-47 are also believed to be allowable. 

Therefore, Applicants respectfully request reconsideration and withdrawal of the 35 
U.S.C. § 103 rejection to claims 2-47, and request allowance of these claims. 
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CONCLUSION 

In view of the above, Applicant respectfully submits that pending claims 2-47 are in 
form for allowance and are not taught or suggested by the cited references. Therefore, 
reconsideration and withdrawal of the rejections and allowance of claims 2-47 is respectfully 
requested. 

No fees are required under 37 C.F.R. 1.16(b)(c). However, if such fees are required, 
the Patent Office is hereby authorized to charge Deposit Account No. 08-2025. 

The Examiner is invited to contact the Applicant's representative at the below-listed 
telephone numbers to facilitate prosecution of this application. 
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Any inquiry regarding this Response should be directed to either Patrick G. Billig at 
Telephone No. (612) 573-2003, Facsimile No. (612) 573-2005 or William J. Streeter at 
Telephone No. (970) 898-3886, Facsimile No. (970) 898-7247. In addition, all 
correspondence should continue to be directed to the following address: 

Hewlett-Packard Company 

Intellectual Property Administration 
P.O. Box 272400 

Fort Collins, Colorado 80527-2400 



Date: ^^J-<=>5^ 
PGBxmj 



Respectfully submitted, 

Michael R. Krause et al., 

By their attorneys, 

DICKE, BILLIG & CZAJA, PLLC 
Fifth Street Towers, Suite 2250 
100 South Fifth Street 
Minneapolis, MN 55402 
Telephone: (612) 573-2003 
Fa^^kftile^tel2) 573-2005 




Patrick G. Billig 
Reg. No. 38,080 



CERTIFICATE UNDER 37 C.F.R. 1.8 : The undersigned hereby certifies that this paper or papers, as described herein, 
are being deposited in the United States Postal Service, as first cjass mail, in an envelope address to: Commissioner for 
Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on this day of April, 2005. 



Name: Patrick G. Billig 
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